数据仓库&数据指标&数据治理体系搭建方法论
数据仓库的基本概念
数据仓库概念
英文名称为Data Warehouse,可简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision Support)。它出于分析性报告和决策支持目的而创建。数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因。基本特征:数据仓库是面向主题的、集成的、非易失的和时变的数据集合,用以支持管理决策。传统数据库中,最大的特点是面向应用进行数据的组织,各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念,是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。
集成性:
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据,这样保证了数据仓库内的数据关于整个企业的一致性。
数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前,必然要经过统一与综合,这一步是数据仓库建设中最关键、最复杂的一步,所要完成的工作有:
要统一源数据中所有矛盾之处,如字段的同名异义、异名同义、单位不统一、字长不一致,等等。
进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成,但许多是在数据仓库内部生成的,即进入数据仓库以后进行综合生成的。
下图说明一个保险公司综合数据的简单处理过程,其中数据仓库中与“保险” 主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同,数据格式也可能不同。把不同来源的数据存储到数据仓库之前,需要去除这些不一致。
数据仓库的数据反映的是一段相当长的时间内历史数据的内容,是不同时点的数据库快照的集合,以及基于这些快照进行统计、综合和重组的导出数据。
数据非易失性主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘,一旦数据进入数据仓库以后,一般情况下被较长时间保留。数据仓库中一般有大量的查询操作,但修改和删除操作很少。因此,数据经加工和集成进入数据仓库后是极少更新的,通常只需要定期的加载和更新。
时变性
数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况,挖掘其中隐藏的模式。虽然数据仓库的用户不能修改数据,但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况,当业务变化后,挖掘出的模式会失去时效性。因此数据仓库的数据需要更新,以适应决策的需要。从这个角度讲,数据仓库建设是一个项目,更是一个过程。数据仓库的数据随时间的变化表现在以下几个方面:
(1) 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
(2) 操作型系统存储的是当前数据,而数据仓库中的数据是历史数据。
(3) 数据仓库中的数据是按照时间顺序追加的,它们都带有时间属性。
数据仓库与数据库的区别
数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。操作型处理,叫联机事务处理 OLTP(On-Line Transaction Processing,),也可以称面向交易的处理系统,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段,主要用于操作型处理,像Mysql,Oracle等关系型数据库一般属于OLTP。分析型处理,叫联机分析处理 OLAP(On-Line Analytical Processing)一般针对某些主题的历史数据进行分析,支持管理决策。首先要明白,数据仓库的出现,并不是要取代数据库。数据库是面向事务的设计,数据仓库是面向主题设计的。数据库一般存储业务数据,数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余,一般针对某一业务应用进行设计,比如一张简单的User表,记录用户名、密码等简单数据即可,符合业务应用,但是不符合分析。数据仓库在设计是有意引入冗余,依照分析需求,分析维度、分析指标进行设计。数据库是为捕获数据而设计,数据仓库是为分析数据而设计。显然,银行的交易量是巨大的,通常以百万甚至千万次来计算。事务系统是实时的,这就要求时效性,客户存一笔钱需要几十秒是无法忍受的,这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的,它要提供关注时间段内所有的有效数据。这些数据是海量的,汇总计算起来也要慢一些,但是,只要能够提供有效的分析数据就达到目的了。
数据仓库分层架构
按照数据流入流出的过程,数据仓库架构可分为:源数据、数据仓库、数据应用通过数据分层管理可以简化数据清洗的过程,因为把原来一步的工作分到了多个步骤去完成,相当于把一个复杂的工作拆成了多个简单的工作,把一个大的黑盒变成了一个白盒,每一层的处理逻辑都相对简单和容易理解,这样我们比较容易保证每一个步骤的正确性,当数据发生错误的时候,往往我们只需要局部调整某个步骤即可。
数据仓库元数据的管理
元数据(Meta Date),主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库(Metadata Repository)来统一地存储和管理元数据,其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。元数据是数据仓库管理系统的重要组成部分,元数据管理是企业级数据仓库中的关键组件,贯穿数据仓库构建的整个过程,直接影响着数据仓库的构建、使用和维护。用户在使用数据仓库时,通过元数据访问数据,明确数据项的含义以及定制报表。
数据仓库的规模及其复杂性离不开正确的元数据管理,包括增加或移除外部数据源,改变数据清洗方法,控制出错的查询以及安排备份等。
数仓建模方法
数据仓库的建模方法有很多种,每一种建模方法代表了哲学上的一个观点,代表了一种归纳、概括世界的一种方法。常见的有范式建模法、维度建模法、实体建模法等,每种方法从本质上将是从不同的角度看待业务中的问题。1. 范式建模法(Third Normal Form,3NF)
范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库的数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则,而在关系型数据库中这种规则就是范式,这一过程也被称为规范化。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。在数据仓库的模型设计中,一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
2. 维度建模法(Dimensional Modeling)
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导,他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。3. 实体建模法(Entity Modeling)
实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件,说明,如下图所示:维度建模
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。1. 维度建模中表的类型
事实表
发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然。
2. 维度建模三种模式
星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心,所有的维度表直接连接在事实表上,像星星一样。星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:a. 维表只和事实表关联,维表之间没有关联;b. 每个维表主键为单列,且该主键放置在事实表中,作为两边连接的外键;c. 以事实表为核心,维表围绕核心呈星形分布;
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的,虽然这种模型相比星型更规范一些,但是由于这种模型不太容易理解,维护成本比较高,而且性能方面需要关联多层维表,性能也比星型模型要低。所以一般不是很常用。
3. 维度建模过程
我们知道维度建模的表类型有事实表,维度表;模式有星形模型,雪花模型,星座模型这些概念了,但是实际业务中,给了我们一堆数据,我们怎么拿这些数据进行数仓建设呢,数仓工具箱作者根据自身60多年的实际业务经验,给我们总结了如下四步,请务必记住!数仓工具箱中的维度建模四步走:实际业务中数仓分层
数仓分层要结合公司业务进行,并且需要清晰明确各层职责,要保证数据层的稳定又要屏蔽对下游影响,一般采用如下分层结构:数据层具体实现
数据源层主要将各个业务数据导入到大数据平台,作为业务数据的快照存储。数据明细层DW
此层命名为轻汇总层,就代表这一层已经开始对数据进行汇总,但是不是完全汇总,只是对相同粒度的数据进行关联汇总,不同粒度但是有关系的数据也可进行汇总,此时需要将粒度通过聚合等操作进行统一。数据应用层APP
数据应用层的表就是提供给用户使用的,数仓建设到此就接近尾声了,接下来就根据不同的需求进行不同的取数,如直接进行报表展示,或提供给数据分析的同事所需的数据,或其他的业务支撑。
最后
技术是为业务服务的,业务是为公司创造价值的,离开业务的技术是无意义的。所以数仓的建设与业务是息息相关的,公司的业务不同,数仓的建设也是不同的,只有适合的才是最好的。指标体系
指标体系是什么?如何使用OSM模型和AARRR模型搭建指标体系?如何统一流程、规范化、工具化管理指标体系?本文会对建设的方法论结合滴滴数据指标体系建设实践进行解答分析。什么是指标体系
1. 指标体系定义指标体系是将零散单点的具有相互联系的指标,系统化的组织起来,通过单点看全局,通过全局解决单点的问题。它主要由指标和体系两部分组成。指标是指将业务单元细分后量化的度量值,它使得业务目标可描述、可度量、可拆解,它是业务和数据的结合,是统计的基础,也是量化效果的重要依据。指标主要分为结果型和过程型:结果型指标:用于衡量用户发生某个动作后所产生的结果,通常是延后知道的,很难进行干预。结果型指标更多的是监控数据异常,或者是监控某个场景下用户需求是否被满足
过程型指标:用户在做某个动作时候所产生的指标,可以通过某些运营策略来影响这个过程指标,从而影响最终的结果,过程型指标更加关注用户的需求为什么被满足或没被满足
为什么搭建指标体系
1. 衡量业务发展质量指标体系可以反映业务客观事实,看清业务发展现状,通过指标对业务质量进行衡量,把控业务发展情况,针对发现的业务问题聚焦解决,促进业务有序增长2. 建立指标因果关系主要明确结果型指标和过程型指标关系,通过结果指标回溯过程指标,找到解决问题的核心原因3. 指导用户分析工作目的建立产品评估体系、活动效果评估体系、智能运营分析体系4. 指导基础数据建设明确基础数据建设方向,集中资源,避免过程和结果分析指标数据的遗漏或缺失5. 指导内容产品建设结合用户的业务场景来进行使用,多个不同的指标和维度可以组合起来进行业务的综合分析,用户可通过指标的变化看到整体业务的变化,并能够快速发现问题、定位问题6. 统一指标消费口径企业内统一关键指标业务口径及计算口径,统一企业业务目标,实现自上而下目标驱动如何搭建指标体系
指标体系建设的常用方法是通过场景化进行指标体系的搭建,以用户的视角场景化思考,自上而下业务驱动指标体系建设,所以要在特定场景下做好指标体系建设,需要先选好指标,然后用科学的方法搭建指标体系。1. 科学方法选指标选指标常用方法是指标分级方法和OSM模型。指标分级主要是指标内容纵向的思考,根据企业战略目标、组织及业务过程进行自上而下的指标分级,对指标进行层层剖析,主要分为三级T1、T2、T3。T1指标:公司战略层面指标
T2指标:业务策略层面指标
T3指标:业务执行层面指标
O
S
M
O:用户来使用滴滴这个产品,需求和目标是什么?
用户需求及目标是便捷、快速打到车,安全到达目的地
那如何让用户感受到自己的需求被满足了呢?
S:滴滴做的策略是:
便捷方面,提供了独立APP版本、小程序版本,还可以多渠道打到车,例如在高德、微信、支付宝都有打车入口;起始、目的地地图智能精准定位;最优路线选择等
快速方面,针对不同人群不同诉求提供了多品类产品选择,例如快车、优享、拼车、出租车等业务,根据早晚高峰提高热点区域运力,减少用户排队时间
安全方面,司机准入机制,司机合规机制,司机画像
M:我们需要针对这些策略去做指标,在这里面我们的指标分别是结果指标和过程指标:
结果指标:渠道转化完成率、乘客取消率、供需比、司机服务分
过程指标:渠道发单数、渠道完单数、排队乘客数、乘客排队时长、司机好评率、司机接单量、司机取消数等
指标选取之后,下面就是最重要的分析维度选择了,前面指标体系定义里讲过维度是指标体系的核心,没有维度,单纯说指标是没有任何意义的。所以维度选择层面主要通过数据分析视角结合实际分析业务场景来确定。例如城市维度、商圈维度、渠道维度、时间维度、用户标签维度等。
AARRR模型
A拉新
A活跃
R留存
R变现
R推荐
"人"的视角
"货"的视角
"场"的视角
怎么管理指标体系
1. 痛点分析主要从业务、技术、产品三个视角来看:业务视角
技术视角
产品视角
技术目标
业务目标
产品目标
规范定义
数据域指面向业务分析,将业务过程或者维度进行抽象的集合。其中,业务过程可以概括为一个个不拆分的行为事件,在业务过程之下,可以定义指标;维度,是度量的环境,如乘客呼单事件,呼单类型是维度。为了保障整个体系的生命力,数据域是需要抽象提炼,并且长期维护更新的,变动需执行变更流程。业务过程指公司的业务活动事件,如呼单、支付都是业务过程。其中,业务过程不可拆分。时间周期用来明确统计的时间范围或者时间点,如最近30天、自然周、截止当日等。修饰类型是对修饰词的一种抽象划分。修饰类型从属于某个业务域,如日志域的访问终端类型涵盖APP端、PC端等修饰词。修饰词指的是统计维度以外指标的业务场景限定抽象,修饰词属于一种修饰类型,如在日志域的访问终端类型下,有修饰词APP、PC端等。度量/原子指标原子指标和度量含义相同,基于某一业务事件行为下的度量,是业务定义中不可再拆分的指标,具有明确业务含义的名称,如支付金额。维度维度是度量的环境,用来反映业务的一类属性,这类属性的集合构成一个维度,也可以称为实体对象。维度属于一个数据域,如地理维度(其中包括国家、地区、省市等)、时间维度(其中包括年、季、月、周、日等级别内容)。维度属性维度属性隶属于一个维度,如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。指标分类主要分为原子指标、派生指标、衍生指标原子指标
派生指标
事务型指标
存量型指标
衍生指标
模型设计
主要采用维度建模方法进行构建,基础业务明细事实表主要存储维度属性集合和度量/原子指标;分析业务汇总事实表按照指标类别(去重指标、非去重指标)分类存储,非去重指标汇总事实表存储统计维度集合、原子指标或派生指标,去重指标汇总事实表只存储分析实体统计标签集合。指标体系在数仓物理实现层面主要是结合数仓模型分层架构进行指导建设,滴滴的指标数据主要存储在DWM层,作为指标的核心管理层。指标体系元数据管理
维度管理包括基础信息和技术信息,由不同角色进行维护管理。基础信息对应维度的业务信息,由业务管理人员、数据产品或BI分析师维护,主要包括维度名称、业务定义、业务分类。技术信息对应维度的数据信息,由数据研发维护,主要包括是否有维表(是枚举维度还是有独立的物理维表)、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。如果维度有维度物理表,则需要和对应的维度物理表绑定,设置code和name对应的字段。如果维度是枚举维,则需要填写对应的code和name。维度的统一管理,有利于以后数据表的标准化,也便于用户的查询使用。指标管理包括基础信息、技术信息和衍生信息,由不同角色进行维护管理。基础信息对应指标的业务信息,由业务管理人员、数据产品或BI分析师维护,主要包括归属信息(业务板块、数据域、业务过程),基本信息(指标名称、指标英文名称、指标定义、统计算法说明、指标类型(去重、非去重)),业务场景信息(分析维度,场景描述);技术信息对应指标的物理模型信息,由数据研发进行维护,主要包括对应物理表及字段信息;衍生信息对应关联派生或衍生指标信息、关联数据应用和业务场景信息,便于用户查询指标被哪些其它指标和数据应用使用,提供指标血缘分析追查数据来源的能力。原子指标定义归属信息 + 基本信息 + 业务场景信息派生指标定义时间周期 + 修饰词集合 + 原子指标修饰类型主要包含类型说明、统计算法说明、数据源(可选)指标体系建设流程
建模流程建模流程主要是从业务视角指导工程师对需求场景涉及的指标进行主题抽象,归类,统一业务术语,减少沟通成本,同时避免后续的指标重复建设。指标体系图谱建设
指标体系图谱概述指标体系图谱也可称为数据分析图谱主要是依据实际业务场景抽象业务分析实体,整合梳理实体涉及的业务分类、分析指标和维度的集合。建设方法:主要是通过业务思维、用户视角去构建,把业务和数据紧密关联起来,把指标结构化分类组织建设目的:对于用户:
对于研发:
指标体系产品化
支撑指标管理规范从方法到落地的工具,自动生成规范指标,解决指标名称混乱、指标不唯一的问题,消除数据的二义性
统一对外提供标准的指标口径和元数据信息
这部分整体介绍了指标体系建设方法论和工具产品的建设情况,目前指标字典和开发工具已实现流程打通,与数据消费产品的打通后续会通过DataAPI方式提供数据服务,规划建设中。
数据治理
一、数据治理 治的是“数据”吗?
数据是指对客观事件进行记录并可以鉴别的符号,是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。其实在我看来,数据可以分为两个部分,一是数字,二是文字。数字是没有意义的抽象符号,数据是有意义的数字。文字表意,数字表量,当两者结合起来,数据就产生了。
在我们的生活和工作当中,数据无处不在。对企业来讲,有很多数据是无关企业重大利益的数据,是没有治理的必要的。数据治理的对象必须是重要的数据资源,是关乎企业重大商业利益的数据资源,这样的数据资源可以称其为“数据资产”。正如北大教授王汉生先生所说:“数据治理不是对“数据”的治理,而是对“数据资产”的治理,是对数据资产所有相关方利益的协调与规范。”
我们需要分开来理解这句话:
①什么是数据资产?
②数据资产的相关利益方是谁?
③协调与规范什么?
先说一说什么是数据资产。我们说不是所有数据都是数据资产,那到底什么才是数据资产呢?
《企业会计准则-基本准则》第20条规定:“资产是指企业过去的交易或者事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。” 如果照猫画虎修改一下,不难获得一个关于数据资产的定义:“数据资产是指企业过去的交易或者事项形成的,由企业拥有或者控制的,预期会给企业带来经济利益的数据资源。”由此可见,数据要成为数据资产,至少要满足3个核心必要条件:
①数据资产应该是企业的交易或者事项形成的;
②企业拥有或者控制;
③预期会给企业带来经济利益。
数据资产的利益相关方是谁?
根据数据资产的定义,数据资产的利益相关方,包括:
①数据的生产者,即通过业务交易或事项产生数据的人或组织。
②数据的拥有或控制者,生产数据的人不一定是拥有数据,就像我们天天上网的各种数据都不归我们自己所有,而是落在了各个互联网公司的数据库中。
③数据价值和经济利益的收益者。数据治理就是对数据生产者、拥有或控制者,数据价值获益者的规范和协调。
都什么是需要协调和规范?
首先是数据的标准化,定义统一的数据标准,“写中国字、说普通话”让数据资产的相关利益方在同一个“频道”沟通。数据的标准化包含几个层面:①数据模型标准化。②核心数据实体的标准化(主数据的标准化)。③关键指标的标准化。
其次是数据的确权。数据一旦成为资产,就一定有拥有方,或者实际控制人,可以把他们统称产权人。与实物不同的是,实物的产权是比较明确的,数据则比较复杂。产品在生产制造过程中,并没有与消费者交易之前,制造商拥有完全产权。产品生产出来后,消费者通过购买支付相应的货币,便拥有了产品的产权。而数据的生产过程就不一样了,我们的各种上网行为每天都会产生大量的数据,例如:网上购物、浏览网页、使用地图、评论/评价……。这些数据到底归谁所有?控制权该如何治理?这是摆在面前的一个难题!我们看到近几年一些不良商家,利用我们的上网数据,导致安全隐私泄密的事件也层出不穷。希望随着技术和商业的进步,尽快能够找到解决方案!
第三是流程的优化。数据治理的两个目标:一个是提质量,一个是控安全。互联网数据的确权目前已经是一个世界级难题,做好企业业务流程的优化可能会对隐私保护起到一定的作用。通过业务流程优化,规范数据从产生、处理、使用到销毁的整个生命周期,使得数据在各阶段、各流程环节安全可控,合规使用。另外,通过一定的流程优化,通过对相关流程进行监管,按照数据的质量规则进行数据校验,符合“垃圾进、垃圾出”的数据采集、处理、存储原则,提升数据治理,赋能业务应用。
二、数据治理 到底在哪里治?
数据治理到底应该放在中台,还是后台,我个人的理解是:小数据标准化治理靠人工、大数据预测性分析靠智能,将两者结合起来:“人工+智能”形成了完整的数据治理技术体系。一个企业的数据治理既离不开小数据的标准化治理,也离不开大数据的预测性分析。
这里的小数据,是在承载事物实体的数据,例如:人、财、物等,是企业所有业务开展的载体。其实说白了就是主数据管理。对于主数据的治理笔者认为是一个后台行为,治理核心是“唯一数据源、统一数据标准”,而要达到这一目标是需要从数据的源头抓起的,并且需要大量的人为干预,比如:数据标准的制定和落实,数据质量的清洗,数据的申请审批,数据的分发和共享等。从这里也能够看出小数据的治理,追求的是标准化、精确化,应该是一个后台行为。
而在大数据时代,得益于大数据技术的突破,大量的结构化、非结构化、异构化的数据能够得到储存、处理、计算和分析,这一方面提升了我们从海量数据中获取知识和洞见的能力。对于大数据,传统的一味追求精确的思维受到了挑战。而对于大数据的治理,允许一定程度上的容错,反而可以在宏观层面拥有更好的知识和洞察力。对于大数据的治理更多的是采用AI技术,例如:知识图谱、语音识别等,对大数据的采集、处理、使用过程加以控制,使其能够合规使用。所以,大数据的治理放在中台似乎更为合适。
三、数据治理 到底应该怎么治?
输入:第2步的输入以及数据治理评估模型、数据治理评估工具(评估指标、打分表等);
输出:数据治理评估结果,数据治理策略,初步的行动方案;
4、数据质量问题根因分析
数据治理的目的是解决数据质量问题提升数据质量,从而为数据驱动的数字化企业提供源动力,而提到数据质量问题,做过BI、数仓的同学一定知道,这是一个技术和业务“经常打架”相互推诿的问题。
某企业数据问题根因分析鱼骨图
产生数据质量问题的原因有很多,有业务方面的、有管理方面的、也有技术方面的,按照80/20法则,80%的问题是由20%的原因造成起的。所以,如果能够解决这20%的问题,就能得到80%的改进。
目标:分析并找到数据质量问题产生的根本原因,制定行之有效的解决方案;
技术工具:头脑风暴、5W1H、SWOT、因果(鱼刺)图、帕拉图等;
输入:数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估结果;
输出:数据质量评估结果、对业务的潜在影响和根本原因。
5、业务影响及实施优先级评估
通过数据治理成熟度评估,从组织、流程、制度、人员、技术等方面找到企业在数据治理的待提升的领域和环节,再通过数据质量根因分析找到数据质量问题发生的根本原因,进一步明确了数据治理的目标和内容。再接下来,就需要确定数据治理策略,定义数据治理的实施优先级。
某企业主数据治理实施优先级评估
不同的数据治理领域解决的是不同的问题,而数据治理的每个领域都有它的实施难点,对企业来说,需要从业务的影响程度,问题的紧急程度、实施的难易程度等多个维度进行分析和权衡,从而找到符合企业需求并满足企业发展的方案。
目标:确定数据治理核心领域和支撑体系的建设/实施优先级;
技术工具:四象限法则(分别从业务影响程度/实施难以程度,问题重要程度/问题紧急程度绘制优先级矩阵)、KANO模型
输入:数据治理成熟度能力评估结果、数据质量问题根因分析结果;
输出:数据治理实施优先级策略
6、制定数据治理行动路线和计划
路线图是使用特定技术方案帮助达到短期或者长期目标的计划,用于新产品、项目或技术领域的开发,是指应用简洁的图形、表格、文字等形式描述技术变化的步骤或技术相关环节之间的逻辑关系。路线图是一种目标计划,就是把未来计划要做的事列出来,直至达到某一个目标,就好像沿着地图路线一步一步找到终点一样,故称路线图。
某企业数据治理实施路线图
企业数据治理的实施路线图的制定是以企业数据战略——愿景和使命为纲领,以急用优先为原则,以分步实施为策略进行了整体设计和规划。实施路线图主要包含的内容:分几个阶段实施,每个阶段的目标、工作内容、时间节点要求、环境条件等。笔者观点:任何一个企业的数据治理都不是一蹴而就,一步到位的,需要循序渐进、持续优化!实施路线图就是基于此产生的,因此说数据治理实施路线图也是说服利益相关者支持的一个重要手段。
目标:确定数据治理的阶段以及每个阶段的目标;
技术工具:路线图法
输入:数据治理成熟度能力评估结果、业务影响及实施优先级评估结果;
输出:数据治理实施路线图或称阶段目标计划
7、制定数据治理详细实施方案
数据治理详细实施方案是用于指导主数据的各项实施工作,一般包括:数据治理核心领域、数据治理支撑体系、数据治理项目管理三个方面。
数据治理总体框架图
数据治理核心领域包括:数据架构、数据服务、元数据管理、数据质量管理、数据标准管理、主数据管理、数据安全管理、数据生命周期管理。
数据治理支撑体系包括:组织(组织架构、组织层次、岗位职责)、制度(管控模式、规章制度、考核机制)、流程(归口部门、管理流程、流程任务等)、技术(数据集成、数据清洗、数据开发、数据应用、数据运营、支撑平台、实施方案等)。
数据治理项目管理方案包括:项目组队、项目计划、质量保证计划、配置管理计划、培训和售后等。
关于数据治理的核心领域,详见笔者之前分享的数据治理框架解读系列文章。
关于数据治理的支撑体系,详见笔者之前分享的数据治理成功关键要素系列文章。
目标:基于数据质量根因分析、业务影响和实施优先级评估结果,制定详细实施方案;
输入:业务影响及实施优先级评估结果,行动路线和计划;
输出:数据治理详细实施方案。
8、数据治理实施过程控制
数据治理实施过程控制是对数据治理项目的范围控制、进度控制、质量控制和成本控制,通过对企业的各项资源的合理协调与利用,而达成的数据治理目标的各种措施。从项目管理的角度来讲也是项目管理的黄金三角:范围、时间、质量、成本。
任何项目的质量和进度是需要良好的项目管理来保证的,数据治理也一样。与传统的软件工程项目不同,数据治理项目有着范围边界模糊、影响范围广、短期难见效、实施周期长等特点:
①范围边界模糊,数据治理涉及到的关键领域如元数据管理、数据质量管理、数据标准管理、主数据管理等很多是存在交叉的,边界很难界定,例如:实施数据质量管理项目,会涉及元数据管理、数据标准管理等,同样一个元数据管理项目也会涉及数据标准和数据质量。
②影响范围广,数据治理的实施不是一个部门能够完成的,是需要从高级管理层、到各业务部门、信息部门通力协作,共同完成的;
③短期难见效,数据治理项目实施完成后,其数据治理的效果被每个业务点滴操作所“稀释”,并不像其他项目,例如BI,那样明显的体现出来,所以主导数据治理的部门会经常遭到质疑。
④实施周期长,在没有清晰的数据治理目标和范围约定的情况下,数据治理是一个“无底洞”。所以,在实施数据治理项目之前制定好实施路线图和详细的实施方案就显得格外重要(第6、7步)。
目标:通过对数据治理项目实施过程的进度控制、质量控制和成本控制以实现数据治理的目标;
技术工具:PP(项目计划)、PMC(项目控制)、IPM(集成项目管理)、RSKM(风险管理)——CMMI过程域;
输入:6-7步的输出:数据治理实施路线图,数据治理详细实施方案;
输出:各项项目控制措施,例如:项目计划、SOW、项目风险列表、项目报告、项目总结等;
9、监控评估数据治理实施效果
随着大数据技术的不断发展,应当从企业的全局数据治理环境的角度,明确数据治理关键技术运用及其标准规范,构建成效评估指标体系,进行治理效果评价;并运用数据治理能力成熟度模型再次评估,界定数据管理层次,从而使得跨系统、跨业务、跨部门的数据治理体系的建设与实施能够通过各方协作顺利进行,实现卓越数据治理,进而通过数据驱动业务、数据驱动管理和运营以实现企业的降本、增效、提质、创新。
某企业数据治理看板(数据已脱敏)
数据治理成效评估指标体系应根据企业及数据治理项目的实际情况制定,一般包括:时间性、数量性、完整性、准确性四个维度。
①时间性即数据的及时性。该维度主要通过源业务系统数据接入的上报及时性、接入及时性等方面进行核对。通过分析月指标、周指标、日指标的数据及时率,得出在规定时间和频度周期内接入系统的比例,以此反映数据接入及时性。
②数量性。该维度是从数据存量,数据增量,数据访问量,数据交换量、数据使用量等指标反映数据的使用情况,可以分为月度指标、周指标、日指标、时分指标等。
③准确性。这个维度主要由各类数据中逻辑的准确性、数据值的准确性、数据频段和字段之间的准确性以及数据的精度等内容组成。该准确率同样包括:月度、每周、每日等准确率指标。
④完整性。此维度主要以单元维度完整性、数据业务维度组合完整性、索引值完整性等不同方面进行核对,是验证数据质量完整性的主要组成部分,包括月度指标、周指标、日指标数据的完整性等内容。
目标:检验各项数据治理指标的落实情况,查漏补缺,夯实数据治理效果;
技术工具:数据治理效果的评价指标体系、各种数据图表工具;
输入:数据治理效果评估指标;
输出:数据治理评估的月报、周报、日报等;
10、数据治理持续改进
数据治理模式应业务化、常态化,不应是一个项目、“一阵风”的模式。
数据治理工作应向企业生产、销售业务一样作为一项重点的业务工作来开展,构建专业的数据治理组织,设置合适的岗位权责,建立相应的管理流程和制度,让数据标准贯彻到每个业务环节,形成一种常态的工作。在笔者看来,在数据源头加强企业数据的治理,让常态化治理成为日常业务,才能从根本上彻底解决企业数据质量的各种问题,让数据真正转化为企业资产,以实现数据驱动流程优化、数据驱动业务创新、数据驱动管理决策的目标。
目标:数据治理常态化,持续提升数据质量,驱动流程优化和管理创新。
输入:持续的、规范的、标准的各项业务操作;数据治理监控的各项指标和报告;
输出:持续输出的高质量的数据。
四、美团配送数据治理实战
从大的阶段来看,数据治理主要分为存量数据“由乱到治”的阶段,以及增量数据严格按照规章制度实施确保“行不逾矩”的运营阶段。在“由乱到治”的过程中,我们需要沉淀出规章制度、标准规范,以及辅以规章制度标准规范实施的工具和组织。在增量数据的运营阶段,我们主要靠对应的组织确保规章制度的落实,通过审计定期考察实施效果,并在长期的运营中不断完善规章制度。在实现存量数据“由乱到治”的阶段,我们主要采取了“两步走”策略,具体执行策略如下所示。
4.1 定标准,提质量
4.1.1 业务标准
业务标准主要是指标的管理和运营标准,我们主要解决三个问题:指标由谁来定义,指标该如何定义,指标该如何运营。基于这三个问题,我们同时提出了三条原则:
业务团队负责指标的定义。
产研商分负责给出指标定义标准和辅助工具,辅助业务团队完成指标的规范定义,达成指标认知一致性这一目标。
最后由指标管理委员会负责指标的管理与运营,保障指标从创建、审核、上线以及到最后消亡的整个生命周期的运营。
为统一指标的定义,我们将指标分为原子指标、衍生指标和派生指标,原子指标通过限定条件和时间的限定生成衍生指标。衍生指标间的“四则混合运算”构成了派生指标。我们不但制定了指标的标准定义,还对其做了准确的资产归属,一个指标出自一个具体的业务过程,一个业务过程归属于不同的数据域,多个数据域构成了美团配送业务线下的分析场景,如下图所示:
指标定义标准
4.1.2 技术标准
这里所说的技术标准,主要是针对数据RD提出的建模标准和数据生产规范,通过建模标准来明确数仓分层架构,并清晰定义每一层的边界与职责,采用维度建模的设计理念。我们的整个仓库架构分为四层:操作层、基础事实层、中间层和应用层,并在每一层同步制定对应的建模规范,如下图所示:
数仓架构以及建模标准
除了建模标准外,我们还制定了涵盖从生产到运维环节的生产规范以保障模型的质量,主要包括上线前的模型评审、生产过程中的完成元数据配置、DQC、SLA和生命周期设置以及上线后的日常运维机制等等。尤其针对元数据管理和生命周期管理,我们分别制定了仓库每一层元数据维护规范和生命周期管理规范,其中元数据管理规范,是依据数仓各层级中各种类型表的建模标准来制定,需要做到规范命名,明确数据归属,并打通业务元数据和技术元数据之间的关系。而生命周期管理规范,是依据配送业务特点和数仓各层级现状来制定的,如下表所示:
仓库各层元数据管理标准
仓库各层生命周期管理策略
4.1.3 安全标准
围绕数据安全标准,首先要有数据的分级、分类标准,确保数据在上线前有着准确的密级。第二,针对数据使用方,要有明确的角色授权标准,通过分级分类和角色授权,来保障重要数据拿不走。第三,针对敏感数据,要有隐私管理标准,保障敏感数据的安全存储,即使未授权用户绕过权限管理拿到敏感数据,也要确保其看不懂。第四,通过制定审计标准,为后续的审计提供审计依据,确保数据走不脱。
安全标准建设
4.1.4 资源管理标准
在资源管理方面,配送技术工程部已经对资源管理涉及的内容进行了合理抽象和准确定义,抽象出租户、资源和项目组等概念。不管是后续的资源预算还是资源管理,我们都需要基于租户和项目组来进行运营,因此,对于业务团队而言,我们只需要将租户和项目组特定职能划分清楚,然后根据不同的职能归属我们的资产,并分配生产该资产所需要的资源。为了方便后续的运营,我们对每个租户和项目组分配确定了责任人,由责任人对运营结果负责。
对业务部门来说,资源管理的关键是对数据资产做清晰的分类,基于数据的分类划分不同的租户和项目组,将数据和租户、项目组实现一一映射。由于租户和项目组都有特定的责任人对其负责,因此,我们通过这种映射关系,不仅实现了资产的隔离,还实现了资产确权(项目组负责人同时对资产负责和运营)。我们整体将数据分为两大类,一是原始数据,包括流到数据中心的数据和日志中心的数据,针对流入数据中心的数据,根据其产生的方式不同,又进一步分为业务数据和流量数据。二是加工数据,对应着数据团队的仓库建设和其他团队的集市建设。基于上述的描述,针对资源管理,我们做了如下划分和确权:
资源划分与管理
4.2 重实施,保落实
第二步,落实第一步的标准,完成数据治理第一阶段的目标,实现存量数据“由乱到治”,并完成相应组织和工具的建设,为实现第二阶段“行不逾矩”这一目标提供工具和组织能力。在此过程中,主要分成三个方面的治理工作:第一,架构模型“由乱到治”的治理,消除模型冗余、跨层引用和链路过长等问题,在架构上保证模型的稳定性和数据一致性;第二,元数据“由乱到治”的治理,实现指标的标准定义、技术元数据的完整采集并建立指标与表、字段的映射关系,彻底解决指标认知一致性,以及用户在使用数据过程中的“找数难”等问题;第三,围绕着隐私安全和共享安全加强数据的安全管控来实现数据走不脱、拿不走,以及隐私数据看不懂这一目标。
4.2.1 架构治理
总结起来,架构方面的治理主要是解决两个问题:第一,模型的灵活性,避免需求变更和业务迭代对核心模型带来的冲击,让RD深陷无休止的需求迭代中;第二,数据一致性,消除因模型冗余、跨层引用等问题带来的数据一致性问题。
模型灵活性
配送解决的是效率、成本和体验三者之间的平衡问题,即在满足一定用户体验的条件下,如何提升骑手配送效率,服务更多的商家,以及如何管控骑手,降低配送成本。抽象到数据层面,基本上反映为上游包裹来源的变化、配送对外提供服务的变化以及对内业务管控的变化。为屏蔽业务迭代给核心模型带来的冲击,我们通过对外封装包裹属性和对内封装运单属性,抽象出包裹来源、提供服务、业务架构等一致性维度,任何业务迭代在数据层面只涉及维度的调整,大大降低了对核心模型冲击和“烟囱式”数据建设问题(新来一个业务,就拉起一个分支进行建设)。
包裹事实分配到运单明细构造单一运单模型
配送指标体系建设的一个重点就是要输出各组织层级的规模、体验和效率指标,实现对运力的有效管控,运力所属组织的层级关系会随业务的迭代而不断变化。为了适应这种变化,避免仅仅因增加维度带来中间层数据的重复建设,我们将组织层级维表由固定层级建模方式调整为桥接表的方式来自适配组织层级变化,从而实现了中间层模型可以自动适配组织层级的变化,能自动产生新维度的指标。如下图所示:
桥接表自适配组织层级灵活变动
在精细化分析的场景下,业务会有分时段、分距离段以及分价格段的数据分析诉求。我们以分时段为例,有晚高峰、午高峰、下午茶等不同的分时段,不同的业务方对同一个时段的定义口径不同,即不同的业务方会有不同的分时段策略。为解决该场景下的分析诉求,我们在事实表中消除退化维度,将原来封装到事实表的时段逻辑迁移到维度表中,并将事实表中的时间进行按特定的间隔进行刻度化作为维表中的主键,将该主键作为事实表的外键。这样,针对业务不同的时间策略需要,我们就可以在维表中进行配置,避免了重复调整事实表和反复刷数的问题。即通过将时间、价格、距离事实刻度化,实现灵活维度分析。如下图所示:
通过将时间刻度化,实现灵活分析
数据一致性
数据一致性得不到保障的一个根本原因,是在建模的过程中没有实现业务口径标签化,并将业务口径下沉到主题层。很多同学在基于需求进行开发时,为实现方便,将新指标口径通过“Case When”的方式在应用层和中间层进行封装开发,主题层建设不能随着业务的迭代不断完善,RD在开发过程中会直接引用仓库的快照表在中间层或应用层完成需求开发。久而久之,就会造成数据复用性低下,相同指标的口径封装在不同的应用表来满足不同报表的需求,但随着应用的增多,很难保障相同指标在不用应用表封装逻辑的一致性,数据一致性难以得到保障,同时这种方式还带来两个严重后果:第一,跨层引用增多,数据复用性低下,造成计算和存储成本的浪费;第二,一旦指标口径发生变化,将是一个“灾难”,不仅影响评估是一个问题,而且涉及该指标的应用层逻辑调整对RD来说也是一个巨大的挑战。
治理前模型架构
因此,我们在“由乱到治”的治理过程中,以衍生事实的方式实现业务口径标签化,将业务逻辑下沉到主题层,消除跨层引用和模型冗余等问题,从技术层面保障数据一致性是该阶段架构治理的重点。我们在业务上,已经划分了严格的数据域和业务过程,在主题建设层面,将业务划分的数据域作为我们的主题,并基于业务过程进行维度建模,将属于该业务过程的指标口径封装在对应业务过程下的衍生事实中。
治理后模型架构
4.2.2 元数据治理
元数据治理主要解决三个问题:首先,通过建立相应的组织、流程和工具,推动业务标准的落地实施,实现指标的规范定义,消除指标认知的歧义;其次,基于业务现状和未来的演进方式,对业务模型进行抽象,制定清晰的主题、业务过程和分析方向,构建完备的技术元数据,对物理模型进行准确完善的描述,并打通技术元数据与业务元数据的关系,对物理模型进行完备的刻画;第三,通过元数据建设,为使用数据提效,解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。
首先,为保障业务标准的顺利实施,实现业务对指标认知一致性这一目标。我们协同产研、商分、业务部门推动成立了度量衡委员会,并建立起指标运营机制,通过组织保障来实现指标运营按照规范的标准和流程实施。如下图所示:
指标注册流程
其次,基于配送业务的现状和未来演进方式,我们进行了高度的业务抽象,完成了主题、业务过程和分析方向等元数据内容的建设。配送即物流,通过线上系统和线下运营,我们将用户的配送需求和美团的运力进行有效的资源配置,实现高服务体验、低成本的配送服务。对外,我们将配送服务通过平台化的方式,提供给用户、商户和电商平台,以满足不同用户在不同业务场景下的配送需求。对内,我们通过不同的调度模式将运单池中的运单调度给合适的骑手来完成履约,平衡规模、成本和体验之间的关系。如下图所示:
配送业务模式抽象
基于以上的业务模式,我们划分了运单主题(对履约数据域下的数据进行构建,支撑规模和体验的数据分析需求)、调度主题(调度数据域下产生的数据,用于支撑调度策略的分析)、结算、评价、投诉、取消主题(用于支撑体验、成本数据分析需求)和管控主题(用于支撑运力奖惩、违规和招募分析需求)等各种主题,并在每个主题下划分对应的业务过程,在应用层制定分析方向的分析标签,通过对元数据内容的建设完成对业务的抽象,为物理模型的刻画准备了基础数据。
第三,元数据服务建设,我们打通了元数据从采集到构建再到应用的整条链路,为使用数据提效,解决“找数、理解数、评估”难题以及“取数、数据可视化”难题。在整个建设过程中,我们围绕着元数据采集、元模型构建、元数据服务以及最后的产品应用进行展开,整体架构如下图所示:
元数据建设架构图
元数据采集
元数据采集分为人工录入和自动抽取,通过人工录入的方式实现物理表的准确归属(包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等)以及指标的采集,从而完成技术元数据和业务元数据的采集,通过自动抽取的方式完成生产元数据的采集和使用元数据的采集,主要包括:物理模型的依赖关系、存储占用、热度、等信息。
元模型构建
分为以物理表为核心的基础元模型构建,以及以血缘为中心的血缘元模型。基础元模型构建以物理表为中心,打通其与技术元数据(主题、业务过程、Schema)的关系,实现了物理表的清晰归属,打通其与生产元数据的关系,为其加上了物理表查询热度、资源消耗、查询密级等生产使用信息,打通其与指标、维度和应用的对应关系,为上层的取数应用建立了完备的元数据。血缘元模型以血缘为中心,不仅构建了从上游业务表到仓库离线表的物理血缘,而且打通了仓库离线表到下游对应报表的血缘,为后续的影响评估构建了完备的元数据基础。
元数据服务
统一元数据服务(OneService),主要提供两类元数据服务,提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。
元数据应用
主要孵化出了三个产品,以“找数、理解数、影响评估”为应用场景的数据地图(Wherehows),以“取数、数据可视化”为应用场景的数据可视化(QuickSight),以及以管理审计为目的的管理审计报表。
4.2.3 安全治理
安全治理主要加强了敏感数据的安全治理和数据共享环节的安全治理。通过对隐私数据的安全治理,不仅要保证其在存储环节的不可见性,而且还要保证在其使用环节对用户进行双重鉴权,字段的密级鉴权和解密的密钥鉴权;通过对数据共享环节的安全治理,我们在数据分级分类的基础上,使数据的权限控制从表级权限控制扩展到行级权限控制。
敏感数据安全治理
敏感数据的安全治理,主要是解决敏感数据的存储安全和使用安全。离线场景下,敏感数据存储安全要解决两大挑战:
确保仓库侧处理方案既要屏蔽上游业务系统变动带来的影响,又要屏蔽自身策略对下游BI系统的影响。
要避免敏感数据在整个加工链路中的扩散。
因此,为解决仓库处理方案与上游业务系统和下游BI系统的解耦问题,我们在上游敏感数据落到ODS环节,确保落到ODS层的敏感数据必须是明文,为保障其安全,对ODS层的所有数据进行文件加密,但是在使用层面,对下游链路透明保障下游链路的正常生产,并限制ODS层数据权限的开放。
ODS层数据只用于安全生产,通过此方案既屏蔽了上游处理方案对仓库的影响,又解决了敏感数据的安全问题。当数据从离开仓库时,在传输环节对敏感数据进行可逆操作,将敏感数据以明文的形式推入BI库,实现与下游BI系统的解耦。为解决敏感数据在整个生产链路的扩散,我们在快照层对敏感数据进行脱敏处理,从快照层开始消除敏感数据,为保障敏感数据的可逆性,将ODS层的敏感数据抽取到安全库中并进行加密存储,实现安全独立管理。具体执行如下图所示:
针对敏感数据的使用安全,我们通过对敏感字段的权限控制和对解密密钥的权限控制,来实现敏感数据使用安全这一目标。针对单独抽取的敏感数据,我们除了针对敏感数据设置其相应的密级确保敏感数据的权限管控外,还基于"暗语"的加密方式为每个项目组分配一个相同的密钥,并且将该密钥存放到与Hadoop集群集成的KMS进行管理(确保支撑离线计算的高并发),确保解密时实现密钥的权限管控。
共享环节安全治理
针对共享环节的安全治理,我们主要是在数据生产环节完成数据的分级分类和数据确权,在数据的使用环节完成数据的表级权限控制和行级权限控制。确保数据在使用环节规范的审批流转,权限开放以后的安全审计,保证数据走不脱。
首先,我们在生产环节B3、B2、B1层数据按照主题或实体C层数据按照应用方向进行逻辑划分,并设定资源的密级和权限负责人。特别地为实现B3层数据在查询环节可按照业务线进行权限管控这一目标(即行级鉴权),针对B3层数据,我们标记该数据需要在查询环节进行行级权限管控,标记使用行级鉴权所需的字段和该字段对应的枚举值。
其次,在使用环节,我们按照资产密级和使用人角色完成数据的审批流转,实现数据的安全共享。
第三,针对B3层数据,审计是否设置了行级权限管控。在数据开放时是否存在越权使用的情况,以及针对即将离职员工加强数据的使用审计,保证数据走不脱。
在数据“由乱到治”的治理过程中,我们不仅实现了存量数据的“由乱到治”,并且在此过程中沉淀出了一系列的建模方法论、工具,并建立了相应的安全小组和指标运营组织。同时,我们为后续增量数据治理确保数据建设“行不逾矩”,提供了强有力的组织保障、稳定的辅助工具和严格的执行标准。在数据治理的第二阶段实现增量数据的“行不逾矩”的过程中,我们主要围绕大数据架构审计、大数据安全与隐私管理审计、大数据质量管理审计和大数据生命周期管理审计这四方面的工作展开,保障治理工作的持续进行,不断提高了组织的治理水平。
5. 工具简介
5.1 数据地图(Wherehows)
数据地图作为元数据应用的一个产品,聚焦于数据使用者的“找数”场景,实现检索数据和理解数据的“找数”诉求。我们通过对离线数据集和在线数据集的元数据刻画,满足了用户找数和理解数的诉求,通过血缘图谱,完成物理表到产品的血缘建设,消除用户人肉评估的痛苦。
离线数据场景
1. 关键字检索和向导查询共同解决了“找数据”的问题:大部分的检索数据场景下,数据使用者都可以通过关键字检索来得到匹配结果。剩下的一小部分场景,例如,对于新人入职后如何了解整个数仓和指标的体系(数仓分几层,每层解决什么问题,都孵化出什么模型;整个指标、维度体系都是怎么分类,有哪些指标和维度),这部分场景可以使用向导查询功能。向导查询相当于分类查询,将表和指标按照业务过程进行分类,用户可以按照分类逐步找到想要的表或指标。
2. 我们打通了业务元数据和技术元数据之间的关系,提高了“找数据”的能力:通过“Wherehows”查找到指标后,不仅不可查看指标的业务定义,还能查看指标的技术实现逻辑,指标在哪些维度或维度组合中已经实现,并且能够在哪张表里找到这些维度,或维度组合的指标数据。反之,也可以知道在某个维度下已经实现了哪些指标,对应的指标在哪些表里。这些功能能让用户更加方便地找到想要的数据。
3. 我们提供了较为完善的数据信息,帮助用户更好理解数据:对于表的信息,“Wherehows”除了提供表和字段的中英文名称、描述信息等基础信息外,为了帮助用户更好地理解表的建设思路,我们还提供了表的星型模型(可以关联的一致性维度及对应的维度表)、表的血缘关系等信息。
4. 我们通过评论问答功能,帮助用户可以快速得到问题反馈:如果用户看了信息后还是感到有问题,“Wherehows”提供评论问答的功能,用户通过这个功能可以进行提问,会有相应的负责人进行回复。对于重复问反复问的问题,用户通过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里,不断地对元数据进行补充和完善。
业务数据场景
业务数据场景主要想解决的一个问题是,如何知道一个业务表(MySQL表)有没有同步到数仓。如果没有同步,能够找谁进行同步。因为已经打通“业务表 -> 数仓表 -> 产品”三者之间的血缘关系,我们能够轻松解决业务数据场景的问题。
生产评估场景
在日常数据生产工作中,我们经常需要对表进行影响评估、故障排查、链路分析等工作,这些工作如果靠纯人工去做,费时费力。但现在我们已经打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系,就能够在10分钟内完成评估工作。对于不同的场景,血缘链路提供了两个便捷的功能:过滤和剪枝。例如,某个表逻辑需要修改,需要看影响哪些下游表或产品?应该要通知哪些RD和PM?这种情况下,血缘工具直观地显示影响了哪些负责人和产品,以及这个表的下游链路。
有些表的链路很长,整个血缘关系图很大,这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能,对于没用的、不想看到的分支可以剪掉,从而让整个链路变得更加直观。
5.2 数据可视化(QuickSight)
聚焦于数据使用者“取数”场景,使用QuickSight,用户可以不再关心数据的来源,不再担心数据的一致性,不再依赖RD的排期开发。通过所选即所得的方式,满足了用户对业务核心指标的二次加工、报表和取数诉求。首先,我们通过指标池、数据集等概念对离线生产的指标进行逻辑隔离,针对不同用户开发不同的数据集以达到权限控制的目的,如下图所示:
用户、指标池与数据集间的关系
其次,我们为用户提供一系列的组件,帮助用户基于为其开放的数据集实现指标的二次加工和数据可视化功能,满足其在不同业务场景下的取数和可视化应用。如下图所示:
指标加工组件
6. 总结与展望
经过三个阶段的治理工作,我们在各个方面都取得了较好的效果:
在数据标准方面,我们制定了业务标准、技术标准、安全标准、资源管理标准,从而保障了数据生产、管理、使用合规。
在数据架构方面,我们通过桥接表、时间刻度化、业务口径下沉等手段提升模型灵活性,并保障数据一致性,消除跨层引用和模型冗余等问题。
在数据安全方面,我们加强了对敏感数据和数据共享环节的安全治理,保证数据拿不走、走不脱,隐私数据看不懂。
在元数据建设方面,我们打通了从采集到构建再到应用的整条链路,并为数据使用人员提供数据地图、数据可视化等元数据应用产品,帮助他们解决了“找数”、“取数”、“影响评估”等难题。
未来,我们还会继续通过组织、规范、流程等手段持续对数据安全、资源利用、数据质量等各方面进行治理,并在数据易用性上下功夫,持续降低用户的数据使用成本。
在数据架构方面,随着数据库技术的飞速进步,现在已经有很多数据库能够支持千万级乃至亿级数据的现算先用,我们也在尝试使用这些数据库帮助提升数据开发效率,改善数仓分层管理和应用支撑效率。
在数据产品方面,我们将持续完善数据地图、数据可视化等数据应用产品,帮助用户快速探查、高效分析,真正发挥数据的业务价值。